Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/idpr/idpr-minutes-92jul.txt

Text File | 1993-02-17 | 6KB | 158 lines

Editor's Note: Minutes received 8/5

CURRENT_MEETING_REPORT_


Reported by Martha Steenstrup/BBN

Minutes of the Inter-Domain Policy Routing Working Group (IDPR)

The IDPR Working Group met in two sessions during the July 1992 IETF
meeting in Boston.  In the first session we talked about shorter-term as
well as longer-term work on IDPR, and in the second session we offered a
spur-of-the-moment demo and shared the remainder of the session with the
NIMROD Group.

Shorter-term Topics


   o Work on the Gated Version of IDPR. Currently, Woody Woodburn has a
     version of IDPR that runs as part of gated.  Woody provided a
     detailed description of the status of the gated implementation at
     the first session and at the second session gave a demo of the
     software.  To obtain a copy of the IDPR software, please contact
     [e-mail].  We plan a pilot demonstration of this software
     in the Internet in late summer or early fall.  Moreover, we expect
     that, as a result of this experimentation, we will want to make
     changes to the software and perhaps to the protocols as well.  The
     IDPR Working Group needs a set of people that are able and
     interested in working on enhancing the IDPR gated software.

   o MIB Development.  We need to implement the MIB, and we need to
     update the Internet Drafts describing both the IDPR MIB and the
     IDPR configuration and usage guide.

   o Adding Facilities to the DNS. The DNS should be able to return
     domain information in response to a query giving entity name or
     address.

   o Adding the Capability for Hosts to Request Source Policies
     Dynamically.  In the current version of IDPR, source policies are
     specified as part of path agent configuration and remain active for
     a given host until they are reconfigured.  Thus, hosts needn't do
     anything special to communicate this information to the path
     agents.  We made this choice so that no host changes were necessary
     to reap the benefits of IDPR. However, we expect that in the
     future, hosts may want to have different source policies, depending
     upon the application active at the moment, and hence need a way to
     communicate this information to the path agents.  SRI is working on
     a subset of this problem, but we may require a more general
     solution.


At the Working Group sessions, several of you volunteered to work on the
shorter-term topics, pending approval from employers.  Would those of
you who have obtained such approval and who are still interested in

                                   1





working on these topics, please send mail to me at [e-mail] so
that we can move these efforts along.

Longer-term Topics


   o Multicast Support.  IDPR should have the ability to construct
     multicast trees and establish the appropriate paths associated with
     these trees.  Moreover, IDPR should be able to take advantage of
     intra-domain multicast where available, both for IDPR control
     information distribution and for multicast user applications.  We
     are pursuing solutions targeted for IDPR. However, those of you
     interested in inter-domain multicasting in general may also wish to
     join the mailing list set up by Jon Crowcroft and Tony Ballardie of
     UCL. To subscribe to the list, send email to
     [e-mail].

   o Multipath Support.  IDPR should have the ability to maintain as a
     unit multiple paths of the same service between the same source and
     destination.  Multiple paths provide a vehicle for obtaining
     sufficient bandwidth, for load-balancing, and for providing backups
     when a primary path fails.

   o Resource Allocation.  IDPR should be able to interoperate with
     resource reservation and flow control mechanisms to provide service
     guarantees.

   o Super Domains.  As the Internet grows, one may wish to aggregate
     domains into super domains in order to reduce the amount of
     information and computation related to routing.  Aggregation
     produces a hierarchy of domains.  IDPR should provide a domain
     address format that permits addressing of domains at arbitrary
     positions in a domain hierarchy.


Any comments on any of these topics are most welcome on the IDPR mailing
list, [e-mail].

Attendees

Nagaraj Arunkumar        [e-mail]
Robert Austein           [e-mail]
William Babson           [e-mail]
Tony Ballardie           [e-mail]
Tony Bates               [e-mail]
James Beers              [e-mail]
Lou Berger               [e-mail]
David Bridgham           [e-mail]
Alan Bryenton            [e-mail]
John Chang               [e-mail]
Robert Ching             natadm![e-mail]
Bilal Chinoy             [e-mail]

                                   2





Michael Craren           [e-mail]
Osmund de Souza          [e-mail]
Irina Dobrina            [e-mail]
Tom Farinelli            [e-mail]
Elise Gerich             [e-mail]
William Haggerty         [e-mail]
Dimitry Haskin           [e-mail]
Steven Hubert            [e-mail]
Takashi Ikemoto          [e-mail]
Bob Jeckell              [e-mail]
Matthew Jonson           [e-mail]
Michael Khalandovsky     [e-mail]
John Krawczyk            [e-mail]
Whay Lee                 [e-mail]
Tony Li                  [e-mail]
Anthony Lisotta          [e-mail]
Ed Menze                 [e-mail]
Shehzad Merchant         [e-mail]
Donald Merritt           [e-mail]
Kraig Owen               [e-mail]
Lars Poulsen             [e-mail]
Stephanie Price [e-mail]
Manoel Rodrigues         [e-mail]
Karen Seo                [e-mail]
Frank Solensky           [e-mail]
Martha Steenstrup        [e-mail]
Fumio Teraoka            [e-mail]
Huyen Vu                 [e-mail]
David Wang               [e-mail]
Luanne Waul              [e-mail]
Steven Winnett           [e-mail]
Robert Woodburn          [e-mail]



                                   3